Session Initiation Protocol (SIP) is a signaling protocol for creating, modifying, and terminating multimedia sessions, including Internet telephone calls, with one or more participants. Details about the SIP signaling protocol is set forth in Internet Engineering Task Force Request for Comment 2543 entitled “SIP: Session Initiation Protocol,” March 1999 (hereinafter referred to as RFC 2543), which is incorporated herein by reference. SIP provides an alternative to PBX- or H.323-signaled telephony.
Callers and callees participating in a SIP signaled communication are identified by SIP URLs. When making a SIP call, a caller first locates an appropriate SIP server and sends a SIP request to the server via an IP network. The SIP server may be a proxy SIP server or a redirect SIP server. A common SIP request is an invitation where the caller asks the callee to participate in a session.
FIG. 1A is a functional block diagram for establishing a SIP call via a proxy SIP server 10. The proxy server 10 receives an invitation from a calling device, referred to as a user agent client (UAC) 15, in the form of an INVITE request. The INVITE request includes the SIP URL of a user agent server (UAS) 20 that contacts the callee when a SIP request is received, and returns a response on behalf of the callee.
The proxy server 10 accepts the INVITE request and preferably engages a location server 25 to resolve the UAS URL to a more precise UAS address. For example, a call directed to a generic SIP URL such as, for example, “sales@acme.com” may be resolved to a particular person, such as, for example, “bob@ny.acme.com.”
The proxy server 10 issues a second INVITE request to the more precise UAS address. The UAS 20 receives the second INVITE request and alerts the user of the request by, for example, causing the user's telephone to ring. If the call is answered, the UAS 20 returns a success indication to the proxy server 10 via an OK response. The proxy server 10 in turn forwards the OK response to the UAC 15. The receipt of the success result is confirmed by the UAC 15 by transmitting an ACK request to the proxy server 10, which then forwards it to the UAS 20.
FIG. 1B is a functional block diagram of an alternative method for establishing a SIP call using a redirect SIP server 30. The redirect server 30 accepts the INVITE request and contacts the location server 25 with the UAS URL as done by the proxy server 10 of FIG. 1A. The redirect server 30, instead of directly contacting the newly found address, returns the address to the UAC 15. The UAC 15 confirms receipt of the address via an ACK request.
The UAC 15 issues a new INVITE request to the address returned by the redirect server 30. If the call succeeds, the UAS 20 transmits an OK response and the UAC 15 completes the handshake with an ACK request.
While SIP holds much promise for future Internet telephony applications, no clear migration path has yet been identified from legacy-based telephony systems to SIP-based telephony systems. Proposed SIP-based telephony systems target telephones for UAC and UAS functionality. This generally implies that each telephone must include its own SIP stack and associated processing power. Such a requirement, however, will likely result in telephones in the proposed SIP-based telephony systems to be more costly. Furthermore the existing technology does not allow such SIP-based telephony systems to be backward compatible with legacy telephones.
Accordingly, there is a need in the current art for a system and method for enabling legacy telephones to participate seamlessly in SIP-based telephony systems. Such a system and method should allow legacy telephones to seamlessly make and receive SIP calls with other legacy telephones as well as with telephones with SIP functionality without requiring that such legacy telephones be equipped with their own SIP stack.